|
Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains. SAML is a product of the OASIS (organization) (Security Services Technical Committee ). ''SAML 1.1'' was ratified as an OASIS standard in September 2003. The critical aspects of SAML 1.1 are covered in detail in the official documents SAMLCore〔 and SAMLBind.〔 If you are new to SAML, you should probably read the introductory SAML topic first, and then the SAMLOverview〔 document from OASIS. Prior to SAML 1.1, ''SAML 1.0'' was adopted as an OASIS standard in November 2002. SAML has undergone one minor (V1.1) and one major revision (V2.0) since V1.0, which itself is a relatively simple protocol. SAML 1.0 is of more than historical interest, however, since the US Federal (E-Authentication Initiative ) has adopted SAML 1.0 as its core technology. Fortunately, versions 1.0 and 1.1 of SAML are similar. See SAMLDiff〔 for specific differences between the two standards. This article concentrates on SAML 1.1 since it is an important standard upon which many other standards and implementations depend. Warning: Implementers and deployers should note well that all code examples in this article are non-normative and for illustration purposes only. Consult the (OASIS SAML specifications ) for normative requirements. == SAML 1.1 Assertions == SAML ''assertions'' contain ''statements'' that service providers use to make access control decisions. For instance, ''authentication statements'' assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the principal may be disclosed in an authentication statement. For example, in the authentication statement below, the e-mail address of the principal is asserted to the service provider: MajorVersion="1" MinorVersion="1" AssertionID="buGxcG4gILg5NlocyLccDz6iXrUa" Issuer="https://idp.example.org/saml" IssueInstant="2002-06-19T17:05:37.795Z"> NotOnOrAfter="2002-06-19T17:10:37.795Z"/> AuthenticationInstant="2002-06-19T17:05:17.706Z"> user@idp.example.org urn:oasis:names:tc:SAML:1.0:cm:bearer An e-mail address (as in the above example) will suffice in a large number of situations. In some cases, however, additional information is needed before a service provider can make an access control decision. As an example, suppose that students are allowed to access scholarships data. An ''attribute statement'' can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.) to the scholarships application: MajorVersion="1" MinorVersion="1" Issuer="https://idp.example.org/saml" ...> AuthenticationInstant="..."> AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> Attributes are often obtained from an LDAP directory, so consistent representations of attributes across security domains is crucial. In the above example showing how a student might obtain access to a scholarships application, the service provider is functioning as both a ''policy enforcement point'' and a ''policy decision point''. In some situations, it may be preferable to associate the policy decision point with the identity provider. In this case, the service provider passes a URI to the identity provider who asserts an ''authorization decision statement'' that dictates whether or not the principal should be allowed access to the secured resource at the given URI. MajorVersion="1" MinorVersion="1" Issuer="https://idp.example.org/saml" ...> Resource="https://sp.example.com/confidential_report.html"> The three statement types are not mutually exclusive. For example, both authentication statements and attribute statements may be included in a single assertion (as shown above). This precludes the need to make subsequent round trips between the service provider and identity provider. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「SAML 1.1」の詳細全文を読む スポンサード リンク
|